There are different ways to model NULL values in Anchor Modeling, depending on the exact meaning and reason you are getting the NULL from the source. Is it NULL because you know that it is impossible to have a value at this time or is it NULL because you don't know what the value is but you know that there definitely is a value, but just not known to you?
For attributes:
* Nulls for attributes on a 'typed' anchor could mean that no value is expected for the specified type. The type doesn't have the attribute in question at all. This is represented by the absence of a row in the attribute table.
* Nulls in all or most attributes could be interpreted that a whole entity is no longer active. This is modeled by a separate knotted historized attribute, where the status of the entity is held by values in the knot (active/inactive) over time.
* For nulls representing a lost value, where we once used to know the value, this is normally represented by an extra value in the knot, that explicitly spells out 'Lost' to you. If your attribute is not knotted (those actually rarely lose values), you need an additional attribute that indicate that status of the other attribute. Usually value domains that are not suitable for knotting also have the property that the last known value can be considered valid until replaced by another one.
* Null may also mean 'deleted', the removal of an erroneous value, for which we do not know or should not have a new value. This is handled by doing a physical delete in uni-temporal AM, or if you need to keep a history you must use concurrent-reliance-temporal AM.
For ties:
* If a relationship can change status, for example 'expire', this is done by historizing the tie and adding a knot holding the expiration status. You can then follow which status the relationship had over time.
* If a row turned out to be erroneous it is either physically deleted (uni-temporal) or logically (concurrent-reliance-temporal), if you need to keep a history.
I hope this helps!
