A Logical Unit (LU or LUT) is a blueprint holding a set of definitions / instructions used to create and maintain the data of a Digital Entity (business entity). It is the prototype from which LU Instances (LUI) are created. An LU is defined and configured in the Fabric Studio. These definitions are comprised of three main objects:
LU Table: The definition of tables that hold the data of a Digital Entity including its columns, PKs, indexes and triggers.
LU Schema: The relationship between the LU tables (similar to foreign keys). An LU schema has one LU table defined as its Root Table that holds the Digital Entity’s unique key.
Let’s use an example of a Customer 360 implementation for Company ABC:
A Logical Unit Instance is one instance of a Logical Unit Type – it is a single physical database holding the data of one single Digital Entity in the LUT structure definition. Using our example from above (Customer 360):
Every Fabric project starts by defining its LUs. Analyze the business requirements and understand how the consuming application will use the data. Use this information to define the different Digital Entities to implement and build an LU for each Digital Entity.
Digital Entity data is often split between different data sources. In some cases, it is preferable to create one LU that contains all data sources. In other cases, it is more advantageous to split the LUs and create a separate LU for each data sources.
In general, an LU should be based on the smallest number of data sources, as long as it represents a full 360 view of a Digital Entity.
For example, if you have a Digital Entity called Customer, but different Customer Types (e.g. consumer and business) have different data sources, the recommanded approach will be to create LU for each Digital Entity sub type (in our example, different Customer Types).
Below is a table of pros and cons of each alternative:
A Logical Unit (LU or LUT) is a blueprint holding a set of definitions / instructions used to create and maintain the data of a Digital Entity (business entity). It is the prototype from which LU Instances (LUI) are created. An LU is defined and configured in the Fabric Studio. These definitions are comprised of three main objects:
LU Table: The definition of tables that hold the data of a Digital Entity including its columns, PKs, indexes and triggers.
LU Schema: The relationship between the LU tables (similar to foreign keys). An LU schema has one LU table defined as its Root Table that holds the Digital Entity’s unique key.
Let’s use an example of a Customer 360 implementation for Company ABC:
A Logical Unit Instance is one instance of a Logical Unit Type – it is a single physical database holding the data of one single Digital Entity in the LUT structure definition. Using our example from above (Customer 360):
Every Fabric project starts by defining its LUs. Analyze the business requirements and understand how the consuming application will use the data. Use this information to define the different Digital Entities to implement and build an LU for each Digital Entity.
Digital Entity data is often split between different data sources. In some cases, it is preferable to create one LU that contains all data sources. In other cases, it is more advantageous to split the LUs and create a separate LU for each data sources.
In general, an LU should be based on the smallest number of data sources, as long as it represents a full 360 view of a Digital Entity.
For example, if you have a Digital Entity called Customer, but different Customer Types (e.g. consumer and business) have different data sources, the recommanded approach will be to create LU for each Digital Entity sub type (in our example, different Customer Types).
Below is a table of pros and cons of each alternative: