create design document on database design addressing 'multiple truths'

[JimFuller-RedHat]

Today we ingest 'many truths', for example we may get component information from an advisory or from an sbom or something mundane where we collect information on organisations from multiple different sources (currently assuming name equivalence implies 'they are the same thing').

Something a bit more tricky to handle is the notion of multiple identities for an entity which is a side effect of ingesting 'many truths'.

We need a REST API (and code and logical models) to ingest and mediate these multiple sources of data and continue to be able to work with them in as fine grained a manner as we do today - yet we also need to 'stitch' together a conceptual view on the data, a synthetic single view which is most useful for other apps as well as the UX to use.

One problem with mastering data is approaching it in a piecemeal manner eg. a few queries here, a few queries there ... (heuristics, small decisions get sprinkled everywhere in the codebase) - eventually we might end up with a lot of code (and data) that is intertwingled eg. any change in one place predicates changes elsewhere/everywhere. A further example - imagine when a new version of vex, cyclonedx/spdx or new standards must be supported ... we want to be able to handle these new specifications with minimal disturbance to data model and code.

If we are to master data we should at some point design and implement using well worn strategies - after discussion with @ctron and @dejanb the first step will be the creation of a design document that proposes a few ways of how to achieve this so we can weigh up the pros/cons.