Views:

You can extend LUSID's data model by adding properties to entities. For example, you could add 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 adding 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 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 specifies the domain (entity type to which properties belong) and uniquely identifies and addresses them.
  • 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. Note most entity types such as portfolios and instruments support multi-value properties, but some do not.
  • Whether properties are time-variant (values can vary during different time periods) or perpetual (only one value is effective at a time). Note most entity types such as portfolios and instruments support time-variant properties, but some such as transactions and holdings do not.

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

Note the following:

  • 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:


 

You can interact with property types programmatically:

  • Using the API endpoints in the Property Definitions collection. Note there is also a separate SearchProperties API to retrieve property types by parent entity type.
  • Using the equivalent methods in the LUSID SDKs.
  • If you have a Luminesce license, using dedicated read and write providers.

Note that operations involving adding properties to entities, retrieving properties for entities, and updating or deleting properties are performed using APIs or dashboards specific to that entity type.
 

Explanation: See the big picture

Reference: Understand concepts and implications

How-to guides: Get something done

Keywords: property, data model, definition, custom, extensible data model