You can extend LUSID's data model by attaching properties to entities. For example, you could attach AnalystRating properties to instruments to store values such as AAA, AA and BB, or Manager properties to portfolios to record the names of responsible individuals.

By design, LUSID has a small set of built-in entity types: instrument, portfolio, transaction, holding and so on. Each type has a minimal set of data fields, some of which are optional and either default to sensible values or can be left empty. If suitable data fields do not exist you can store extra information about an entity by attaching any number of properties to it. Subsequently, when you query LUSID to retrieve that entity, you can do so with or without its properties; you can also entitle properties separately so that only certain people can see them.

Note: Properties are the recommended way to extend the data model if values are atomic and non-complex. For values that potentially apply to many entities, and/or are large or complex in nature, we recommend creating custom entities and linking them using relationships instead.

A property must have a property type that defines core characteristics:

  • A 3-stage key (for example, Instrument/BBG/AnalystRating) that uniquely identifies and addresses all the properties of the type.
  • A data type; this can be a primitive type such as string or number, or a complex type that helps maintain data quality by constraining allowed values.
  • Whether properties are single- or multi-value.
  • Whether properties are time-variant (values can vary during different time periods) or perpetual (only one value is effective at a time).

It follows that you must create a property type before you can attach properties of that type to entities.

Note the following:

  • Properties are bitemporal; you can correct any value and retrieve the previous state by rolling back LUSID's as at timeline.
  • Property types, however, are monotemporal. That is, a definition can be updated, and you can retrieve previous definitions by rolling back the as at timeline, but for a given as at datetime the prevailing definition applies to all effective at datetimes.
  • You can create a derived property to act as a ‘golden source’, so for example you could load analyst's ratings from two different data vendors and then calculate an average, or map different rating taxonomies to a standard format.
  • LUSID stores your properties but does not use them in calculation or other business operations. However, there are a number of system properties you can use to store and access business information not available by other means. Before creating a property type, it might be worth checking whether a suitable system property exists.

Providing you have appropriate access control permissions, you can interact with property types using the Data Management > Properties dashboard in the LUSID web app:

Note you attach properties to entities, and retrieve properties for entities, using the dedicated dashboard for that entity type, for example Data Management > Portfolios.

You can interact with property types programmatically:

Note you attach properties to entities, and retrieve properties for entities, using APIs specific to that entity type.

Explanation: See the big picture

Reference: Understand concepts and implications

How-to guidesGet something done