Reporting on historical data - when to use current or historic data (warn user about changing the meaning of a record?)

Question

This is similar to this question

Basically I am writing the database and software for a building monitoring system. The system monitors things like temperature, humidity, pressure of units (such as fridges).

When a report is generated for a particular unit, it has a column for each sensor with the sensor name, with the readings below.

I'm trying to decide whether it should be the names at the time of the reading, or the name as it stands now.

I currently think it should be the latter, because I tend to believe that given the same (primary) key, the meaning of the data it uniquely identifies should not change even if it's attributes do. So, any name changes should be for correction or clarification only, IMO, almost as if the name itself was the primary key (I'm all for natural keys but tend not to use the name of something due to length and possible need for spelling correction - in this case though I have a "SensorNo" field (not ID) which is unique to the unit it is monitoring).

Anyway - this means I can indeed use the current name, and if they change the name of the sensor from perhaps "Air" to "Food", then it should say "Food" on all report data even if it is showing data from before the change, the idea being this change should mean it was always meant to be "Food", not "Air" - it is a correction.

For none "key" data such as "Upper Limit" and "Lower Limit" (the temperature range for instance) the historical data should be used when reporting, in this case because it shows the temperature range of the sensor at the time of the reading.

You could argue it is similar to changing the full-name of a user: it is still the same person, but they may of changed their name, therefore the report history should always show the persons up to date name, otherwise confusion could ensue.

My plan is to allow users to change the name but warn them of the implications first, and state it should only be used for corrections.

What are peoples thoughts on this? How do you handle this situation? I'm interested too in hearing from Catcall who anwered the question linked.

(Please note this is not a discussion about how historical data is stored, I'm already fine with that side of things).

Answer 1

I think you answered by yourself. If they change the name of a field it's a correction (and then they do not need the see the old name in new reports). If they change the sensor name because the meaning is changed then they should ADD a new sensor. I do not think you can really save your users from this kind of mistakes. In some application I saw they DROP the database when they build a new input set (but you can't or you do not want to do this). It may be different if they want to use vendor/model name as tag name (sensor name). In this case it may change during time and probably they want to see the true name for each interval. In this case, if changes are limited to tag name, you can save yourself with a small table to track these changes (id, name, timestamp) and update the hypothetical ResolveTagName(id, time) function to query that table. I have more doubt about historical data for limits because they may change during time (for example the maximum temperature for a part can decrease during time because the part is getting older or because a measurable physical stress, in this case you cannot apply the current limit for an old measure).

Answer 2

"You could argue it is similar to changing the full-name of a user: it is still the same person, but they may of changed their name, therefore the report history should always show the persons up to date name, otherwise confusion could ensue."

Confusion can always ensue. And simple measures cannot prevent that from happening. Suppose a sensor is now named "Air" but used to be called "Food" at some point (and at that point in time there was another sensor named "Air"). How do you think it can be ascertained that no one will ever go check the logs and come up with "hey you give measurements here for sensor "Air" from a year ago, but I checked the logs myself and found completely different numbers".

There are two things you can do. (a) try and make it as clear as you can that if the report says "sensor Air" (2 words), then what it really means is "the sensor which was named "Air" at the time of the creation of the report, but which might have gone under different names prior to the time of creation of the report, and which does not even necessarily need to be the very same sensor as the one that is called "Air" at the time of your looking at the report" (lost count). If you try to explain that to your users, the best you can get is a blank stare, if they don't bluntly turn their backs on you and walk away. If you write it in the manual, you will discover that users never ever read manuals.

And (b) you can try and include indications of past name changes on the report. Do it slightly cryptically (say, an alert string like '*'), and you're guaranteed to get questions about what that means at a time when you have even forgotten it yourself. Perhaps a good option is to print a separate section with the past name changes, right below the title section or so, but if there is no name change history, then print nothing at all (not even the headings for that extra section).

"My plan is to allow users to change the name but warn them of the implications first, and state it should only be used for corrections."

It does not pertain to you to decide that "it should only be used for corrections". Many real-world objects are typically identified in human speak using names, and many of those real-world objects go under different names over their lifetime. You cannot change the fact that names are the most comfortable means of identification in almost any setting I can think of. If Bill Gates' wife wants to go shopping, then would she ask "Honey, can I take the Porsche", or would she ask "Honey, can I take the WOL0x547832187 (which might be the correct unique chassis ID number of Bill Gates' Porsche) ?". Nor can you change the fact that things can change name.