MF_ReadingByHourNoAggregations

Fact

This dimension houses things like equipment orientation (also wind direction as a compass point, N, NW, etc.), operational status information, device condition or state identifiers (open vs. closed) - all things that can't be aggregated.

The grain of this fact table is similar to that of MF_ReadingByHourAccumulating and MF_ReadingByHourSnapshot, except that it goes a level deeper, adding the value to the grain (that is, to the primary key). Each possible value is associated with a row in MD_UnaggregatableReading. The count of those readings (for each hour) is in MF_UnaggRead_Count.

Things recorded here are not really continuous, numberic, aggregatable data even if they look that way. One example is wind direction. For things like wind direction, which can be measured numerically (in this case, in degrees), but can't be aggregated easily, at least not by most business intelligence software, one should aggregate the data into some convenient set of numeric values (e.g., 16 compass points 0, 22.5, 45, 67.5, 90, etc. degrees), then enter only the mode (most frequent value) here, in degrees. This is a kludge. Otherwise, though, we'd have to create dimensions for each measurement of this type - or a separate fact table. Such facts are only semi-aggregatable (ideally one uses the mode, not max, min, avg, etc.).

This table will typically be used in conjunction with the MD_ThingMeasured and MD_UnitOfMeasurement dimensions. Similar materials should be joined, where possible, to identical units of measurement. If necessary, conversions should be done to achieve this. That way, if we want to aggregate measurements across, e.g., multiple locations, or multiple devices, we can be sure the units are compatible.