Configure the object visibility settings

Background and Strategy

Each object in Ursa Studio is assigned to a Layer, describing its stage in the “data journey” from raw source data to finished analytic deliverables.

Among other purposes, an object’s Layer is used to determine which objects can see and invoke it, and which objects it can see and invoke. For example, objects in an “earlier” Layer (i.e., a Layer closer to the start of the data journey) should not be able to invoke an object in a “later” Layer, since this might result in a dependency loop (in which both objects are both dependent on each other, perhaps through a series of intermediate objects).

Another desirable visibility restriction is that objects in the later Layers beyond the Natural Object Layer should not be able to directly invoke objects in Layers before the Natural Object Layer, since those earlier objects will likely only contain data from a single source system and may contain data that have not yet been fully cleaned and conformed to the data model standards. That is, the Natural Object Layer acts as a sort of gatekeeper, preventing users from inadvertently accessing partial and/or unprepared source-specific data.

For this reason, objects in the Source Data Layer (i.e., all Import objects and Registered Table objects, in most cases), should typically only be made visible to a select few Layers: the Semantic Mapping Layer, since the plan under most circumstances is for each source object to undergo semantic mapping before it is used for any other purpose; the Metadata and Integration Layer, which is a special layer used in part to handle unusual integration needs; and the Data Diagnostics Layer, where objects used for exploration and testing of source data are typically housed.

These visibility characteristics are configurable in each object’s Object Metadata panel. The Layer control is used to assign the object to a Layer, and the Is Visible to Layers control is used to identify the Layers whose objects will be able to see and invoke the current object. (Note that there is no Layer control in Import Objects because they are always considered to be part of the Source Data Layer.)

Upon assignment of a Layer, Ursa Studio generates default values for the Is Visible to Layers control, reflecting a sensible configuration. In most cases, this default configuration will be appropriate, but it can be modified by unchecking the Use Layer Default control.

Finally, in some instances, Registered Tables may already contain clean and mastered data conforming to the desired data model structure. (This might be the case if Ursa Studio has been deployed on top of a mature EDW that already performs its own data integration.) It would likely be most appropriate to assign these objects to the Natural Object Layer, or perhaps, in some cases, the Synthetic Object Layer or Data Mart Layer.

Key Diagnostics / Heuristics

1. Do the field names, field values, and grain size of a given Registered Table already conform to the desired data model standards? (This might be the case if Ursa Studio is sitting on top of a mature Enterprise Data Warehouse that requires no additional source data integration or cleaning.) If so, it will likely make sense to select Natural Object in the Layer control. If not, the object should probably be assigned to the Source Data Layer.

Detailed Implementation Guidance

1. Keeping the Use Layer Default checkbox selected is nearly always the sensible choice.

Examples

None