Can an indicator be null?
FWIW, allowing nulls sort of defeats the point of having indicators at all. Indicators are an implementation of Boolean Logic (indeed, many of the object languages have Boolean as a data type), which doesn't work if there are nulls in the relevant attributes. You could go a little deeper into Aristotelian logic, but this is a much longer debate.
The rules I apply are generally a) it is mandatory field, b) values are CHAR(1) of Y/N or T/F, and c) it must have a default value (no nulls). Which default you give it depends on the condition you are using it to describe - as a rule, if the attribute can't be described only in terms of True or False, you probably have an enumerated code set and should avoid using indicators at all. If the attribute can described in terms of the question "Is it...?" then it is an indicator.
Sometimes there are combinations of indicators required to express a particular set of conditions for a query to match against and provide flexibility in the way in which filters in the queries are applied, though it often makes more sense to use multi-value attributes.
Sometimes these get used for decision tables as well, so beware of overuse of this as it implies Yes/No branched logic where some more rational thinking along the Business Decision Model lines which generates multi-value decision outcomes is better.
Questionable. Take for instance the logical delete of a record. The record is inserted, and the isDeleted remains NULL, since it's not part of the facts stored in the record. Only after a logical delete is performed, is that fact added to the database. There the NULL actually has meaning.
The problem with NULL is to retroactively determine what it could mean. But from a design perspective it simply reflects the absence of a fact, nothing more.
The design could also reflect a default value 'False' which would mean 'not deleted'. But again in hindsight it may mean it is actually undeleted. Therefor the NULL, False, True are all valid options. So the design matters.
On interpreting the meanings of NULL without knowing the design issues leads to a big list of possibilities, as Lars stated in his article.
I first encountered the "meaning of null" question many many years ago. It was always a fun question to discuss, particularly during happy hour. My office had a running joke about the "7 meanings of null". 🙂
How to interpret a null and the course of action to follow is, of course, context-dependent. The list below presents some possible meanings of null. And I do recognize that some of these constitute "bad" modelling, but are nevertheless sometimes found out there "in the field".
(1) To-Be-Determined: The attribute needs a value (required) in order for the record/instance to be valid. You-all have this covered in the discussion above.
(2) Unspecified: The attribute eventually needs a value, but it's okay that it's null for now (conditionally optional.)
(3) Not Applicable: The attribute and its value are not applicable to (i.e., does not meaningfully describe) the entity/object represented by the record/instance. (optional) (An example of the bad modelling mentioned above.)
(4) Unknown: The relevance or meaning of the attribute, and therefore the value, to the record/instance is completely unknown - you don't even know if the attribute is applicable or not. (more bad modelling)
(5) No Value Specified: There is some external, context-dependent reason (beyond "will assign a value later") for not assigning a value to the attribute. The attribute is applicable and optional/required may or may not defined.
(6) Context-dependent: The modeller/developer assigns or interprets the null value to mean something to the consuming application. (possible bad modelling - the IsDeleted example Marco presented is example of this and is a reasonable modelling decision.)
(7) Null: the meaning of the null is null