Object Workshop Common Constructs

Indexed Fields and Analytic Fields

As with Measure Workshop, users have the option to denote published fields or derived fields as being analytic. In Object Workshop, there is also an option to set a field as indexed. The indexing option does just what you would expect: It instructs the client database to add an index to that column of the table. Setting a field as analytic, meanwhile, is only passed up as an instruction to Measure Workshop if the measure element inherits the field settings of its underlying object. 

Object Metadata

Users can add metadata, such as temporal class and case ID, to objects to help provide intelligent guideposts to downstream applications.

Locking Assets

Productionized objects, along with measures and models, can be “locked” via the Access and Use Restrictions panel. No edit is allowed on a locked asset until it is explicitly unlocked. Any user with edit privileges can unlock a locked asset, but both the locking action and the unlocking action are logged in the asset’s version history. 

Primary Keys

Primary keys will be added whenever possible to objects upon ELT. Generally, users will be able to dictate whether or not the primary key will be naturally derived from the case field, or whether the primary key will be a new autonumber field named ursa_serial_id, by means of a checkbox in the "Object Metadata" panel, immediately below the control to dictate the case field. This checkbox will be checked by default for objects with a case field defined, which means that the tables will default to using the case field to drive the primary key.

When being driven by the case field, the primary key is not necessarily the same as the case field: for interval objects, the primary key will be the case field plus the interval start and end dates.

For timeline objects and the medication therapy episode object, the primary key will always be driven by a case field that is automatically determined. For these object types, no checkbox will be shown.

For bespoke SQL and registered table objects, it is not possible to add an autonumber ursa_serial_id, so if the primary key is not to be driven by the case field then there will be no primary key on the table. Import objects will always use ursa_serial_id as their primary key.

For all these permutations, a tooltip alongside the checkbox will explain the primary key that will result by following the above rules.

For views and RDBMSes that do not support primary keys, it will not be possible to add a primary key, but validation will be performed during ELT and report run to verify that the fields chosen as the primary key are unique and not null.

These primary keys represent an added rigor into the ELT process that might cause objects to fail the validation/post-processing step. Generally, this will be because the case field on the object is not unique or non-nullable as it should be, and the error will be an opportunity to inspect the construction of the object. However, for users in a hurry, the escape hatch of unchecking the new checkbox will cause the object to fall back to the use of ursa_serial_id as the primary key, which should cause the object to build without error.

Foreign Keys

Foreign keys can be designated in the Object Metadata panel for fields with a field group of Data Model Keys. These keys are strictly informational and are not enforced in the database.

Data Review

Users with privileges for Object Workshop can see the data within the table managed by the object via the Data Review link to Analytics Portal, giving Data Review all the features of Analytics Portal. Users can see case detail via the Case Review screen and aggregate detail via Measure Explorer. Each object can have its own Boards and News Feed. 

Clicking the Data Review button at the top of the screen will open Data Review in a new screen. Objects will be treated as static measures with one row per case. 

Visible Data Model

Measure Workshop and Object Workshop build off of a cached snapshot of what they understand their visible data model to be. The cached snapshot is generated by inspecting the actual tables and views in the client database and marrying them up to the objects that manage them. If a table does not exist—perhaps the object has been created but the table has not yet been created through an ELT—then the object will not appear as an available object. 

The snapshots are recached whenever Ursa Studio performs an action that might affect them, such as an ELT or the edit of an object's metadata. However, if the objects have changed through a manual process that Ursa Studio did not manage, the data model should be recached manually. This can be done via the recache button at the top of the Object Workshop dashboard. Running this action does not kick off an ELT of the underlying tables.

Users can exert fine-grained control over which objects appear for selection in which downstream layers. Any object can be visible to any combination of layers, including measures. Because such fine-grained control might be too onerous for every object and may be brittle to future changes to the available layers or their desired ordering, a Use Layer Default checkbox will automatically set the visibility controls of the object to be a sensible default given the layer of the object. Typically, this means that the object will be visible to the layer it is in, as well as any downstream layers. For select layers, however, special rules are built in—for example, natural objects are not visible to other natural objects.

Users will be able to see these rules in real time by looking at the visibility control, which will be disabled so long as the Use Layer Default box is checked. The default rules are dynamic, so that any later changes to the layers or their ordering will immediately be reflected in all objects set to use the defaults.

Dedicated Precursors

Dedicated Precursors represent an exception to the typical rules of layer-based visibility controls. Users can designate objects as being a dedicated precursor to a selected terminal object. Dedicated precursors will only be visible to the terminal object and other precursors of the same terminal object. When the terminal object is selected for ELT, its dedicated precursors will automatically be included in the ELT plan, but they can be excluded if desired.

Standard Validation

For most Object Workshop objects users can opt in to having pre-set validation options. The options include validating that an object has at least one row, and that the row count has not changed by more than a given percentage since the last build.

Column Naming

Unlike Measure Workshop, Object Workshop provides a mechanism to set the names of both published fields and published derived fields. A sensible default is always available based on the field name, using a reverse-lookup of default labels. For example, if “hsp” is set in the default labels to mean “Hospital,” then the default column name for a field labeled “Hospital ID” will be “hsp_id.” In the case of multiple abbreviations mapping to the same word, the default will use the dominant key as specified in the default labels setup.

Users can always enter their own column names, overriding the defaults. The application will enforce that the names are valid SQL identifiers.

SQL Diff View

Users with SQL visibility privileges will be able to see a SQL diff representation of object edits from the Revision History panel. Users can open a new tab showing the diffs by clicking an icon-button alongside the edit. The icon-button will only appear if any hidden comments are revealed.