Hey! I would be very grateful to have some feedbacks on a specific Modeling scenario in Energy Sector:
We want to Model a Energy Meteringpoints with Loadprofiles in Data Vault. As central Business Entity there is the Meteringpoint with a Meteringpoint ID as BK.
Each Meteringpoint has several contextual attributes such as Location, Type,… and Relationships to other Entities (Customer).
Loadprofiles are time series data measured by the Meteringpoint. A Measurement is representing a summarized Energy consumption in a Time Interval (e.g. 5min).
Loadprofiles only relating to single Meteringpoint and no other Business Entity. A Meteringpoint can have multiple Loadprofiles in parallel (Consumer Energy, reactive Energy, ..) which representing Independent time series.
A Loadprofile Measurement is uniquely identified by the following Attributes :
Meteringpoint
Channel
Measurement-Timestamp
Measurements can be corrected by new values some days later(old value can just be overwritten). Loadprofiles are stored in two different source systems which have partly different Table informations about Loadprofiles beiße the Measurement Itself.
In my mind there are the following Modeling options:
Hub Meteringpoint + Sat lp_measurement
Storing Source System Tables of Load Profiles Measurements in MAS
MAS Key would be timestamp + Channel to have HK + LDTS unique
Hub Meteringpoint + NH-Link Loadprofile
NH-Link with only one Hub Reference (Meteringpoint)
measurement timestamp and Channel as dependend Child Key (included in NHLink HK)
Value as NH-Link Payload
Storing any other attributes about Loadprofile measurements in NH-Link Satellites (Status, Quality, …)
Loadprofile as own Hub with Satellites
From my Perspektive it feels wrong to Store the Loadprofile Measurements in a MAS with a timestamp in MAS Key. Also Loadprofile Hub would be a Weak Hub because it always depends on the Meteringpoint.
Im Open to any Feedback or advice regarding best practice
I agree with the conclusion that a Loadprofile shouldn’t be modelled as its own Hub. It’s fully dependent on the Meteringpoint, and the combination of Meteringpoint + Channel + Measurement‑Timestamp doesn’t behave like a stable enterprise business key - especially when different source systems structure or correct these measurements differently.
Storing the data in a MAS also feels like the wrong fit. MAS patterns aren’t designed for high‑volume, timestamp‑driven transactional data, and keying a MAS by timestamp just to make LDTS/HK unique doesn’t match the intent of that construct. A Weak Hub has the same issue: the Loadprofile has no standalone business meaning outside the Meteringpoint.
The main challenge I see is that the typical justification for a Non Historised Link involves connecting two business entities. In this case, there is no obvious second Hub. Channel might become one, but only if it is treated as a true business concept. Without that, modelling an NHL that anchors only to Meteringpoint feels structurally unusual.
My instinct has me leaning towards a Satellite off of the Hub for Meeteringpoint, using Channel and Measurement-Timestamp as dependent keys but I would want to give it a proper run through to be sure.
I agree to the conclusion to end up in a satellite, although it feels counterintuitive.
The alternative - an ‘unusual link’ - would not fit your needs in my opinion, because as you suppose to model it, you cannot support the need for backwards changing values (unless you would actually overwrite the value).
A suggestion I can add would be to not create a MAS, but multiple satellites, one per channel, assuming that it is a limited number of channels and not suddenly changing (new or disappearing channels).
In the beginning i had also Standard Satellites in mind, but to have events in it feeled incorrect. Especially when Loadprofiles are not absolutely contextual Data of the Meteringpoint itself from my understanding.
@dylan.roe Channels are not really a Business Concept. At least they only exists in the Context of a Loadprofile and their are only a few types of it 10-20 which are regularly not changing.
@Klaas.vanVeelen I’m also not the bigfest fan of the NH-LINK but there are two considerations:
Its valid in this scenario to overwrite the value if they are getting corrected afterwards
Heya, my initial gut feeling was 1 DSAT “Dependent child key“ with pk[METER_HK, LDTS, CHANNEL, EFFECTIVE_TS] (.. type=’reading’|’update’..
A LINK or NH-LINK: doesn’t make sense as probably channel not business entity.
Seems its either 1 DSAT for all channels vs 1 SAT per semantic channel (wondering if 99 channel_id’s could be arranged in 6 business semantics for |example.. that would minimize number of SATs, but maybe this is more BV (Business Vault thingy), and remembering the standard for SATs to be split:
per speed
per source data system
So i core SAT for scd meter attributes+1 DSAT per source data system
Yeah, my feeling is not so much against a (single-hub-)LINK as such, but on the approach to consider it NH, whereas it’s actually historized (there are changes in the data).
The effect of a backdated change not being captured, is that you can no longer prove to have been correct in reports that were created (and decisions made?) on the dataset before the change.
So that’s from a ‘formal perspective’ which might not be that ‘real-life’ an issue. I’ve been working in the (HV)energy industry myself, so I’m aware that these changes are more the exception than the rule and the impact on the actual figures is very-very-limited. So I could understand you chosing the ‘practical option’ (in the Bus.Vault?).
My advise would be to at least involve business stakeholders in the decision to not be 100% auditable by overwriting the values.
Unfortunately, we use datavault4dbt, which as far as i know, does not support dependent child keys in satellites as dedicated Concept. Only in links..
What do you think would be the second-best option? MAS would come closest to the proposed solution and then Channel as MAS-key instead Dependen Child key. I wouldnt like to split Sats manually by Channel
@Klaas.vanVeelen How would you think about a historized link with channel as dependent child key and then a satellite with the measured values? That would guarantee the Historizstion for both Channel and Measures value.
A SAT with dep-key forces respective parent hub or link to also have the dep-key column., and participating on parent hash_key so SATs pk remain classic (hk,ldts):
So you saying is datavault4dbt supports parent hub or link to have dep-key as both column+ part of hk calculation, but not possible add dep-key as attribute on SATs is it?
