Hierarchy Rules

For clients that have multiple brands or divisions, Cheetah Digital by Zeta supports a "Parent / Child" database architecture. This architecture is designed around a single database (referred to as the "Parent" system) with all of the brands residing in that database, but separated into different views (each of which is referred to as a "Child" system).

The Parent / Child architecture is very flexible. For example, you can define tables at the Parent level, thereby allowing one or more Child systems to access data in that table. Or, tables can be Child-system specific, with data optionally loaded at the Parent level, or at the Child level. Likewise, at a more granular level, individual fields in a Parent-level table can be accessible to only the Parent, or potentially to one or more Child systems.

A user working within the Parent system has access to all data within all Child systems (except data contained within tables and / or fields built directly within, and loaded directly to, a Child system). However a user working within a Child system can't see Parent-level data, nor can he or she see any data in any of the "sibling" views.

In order to manage the complex question of "Who has access to what data?" the platform allows you to define special rules that are applied when data is imported into the system. These rules, called Hierarchy Rules, are a top-down configuration feature set in the Parent system that determine which records a Child system can access. This feature creates a distinct database "view" (or subset of records) relevant for each Child system. To leverage this configuration option, all data is loaded through the Parent system. During the import process, a Hierarchy Rule can be utilized to "tag" a Primary Key in order to make it accessible to a Child system (or potentially, to more than one Child system). The assignment of data to a Child system (or systems) can be as simple as looking at one value in one field (for example, a Brand identifier), or a more complex rule based on a Filter that looks at the values in multiple fields.

Building Hierarchy Rules

A Hierarchy Rule consists of one or more logical criteria. These criteria are referred to as "Rule / System Pairs" because they consist of both a condition to be met (the "Rule") and a resulting system to which data will be made available. A Hierarchy Rule can consist of one to many different Rule / System Pairs in order to make data available to a Parent system, or to one or more Child systems. Hierarchy Rules also support the use of a "default" system, which is used when a record doesn't meet any of the other defined Rule / System Pairs.

Cheetah Digital provides two different methods (called "query types") for establishing how you want to identify the "Rule" -- either by inclusion in a Filter, or by values in a specific field. You must choose one of these two query types for your Hierarchy Rule; you can't use both types within the same Hierarchy Rule.

The platform also supports two different logical structures ("IF > ELSE IF" and "IF > IF") for defining a Hierarchy Rule with multiple conditions. The IF > ELSE IF structure is useful if you know you want a record to fall into only one "rule," and be accessible to only one system. The platform works from the top down, evaluating records against the first rule. Only the non-matching records drop down to the second rule. Once a records matches a rule, it's removed from any further evaluations. Therefore, the sequence of the rules is important, because even if a record qualifies for more than one rule, it's assigned only to the FIRST system to which it matched.

With the IF > IF structure, a record can potentially match to multiple rules, and therefore be made available to multiple systems. The sequence of the rules doesn't matter, as the system evaluates every record against every rule. So, even if a record met the first rule, it would still get evaluated against the subsequent rules as well.

Example

The following example illustrates the flexibility of Hierarchy Rules.

Let's say you have four brands, each of which is set up within their own Child system within the Parent system. Three of these brands (A, B, and C) share a Store table that contains store details, location, contact information, and so forth. Brand D doesn't have brick-and-mortar stores, and therefore they don't need to see this table. 

This Store table is created within the Parent system, and Brands A, B, and C are given access to this table. However, each Brand has its own unique set of stores. Therefore you could limit access to brand-specific stores, by establishing which Child systems can access which Primary Keys on the Store table. This configuration would allow each Child system to see only the Store table records that were relevant to their brand, instead of seeing all available Store table records. You could use a "Brand Identifier" field to determine which Child system has access to which record. For example, your Rule / System Pairs might look like this:

  • IF 'brand_identifier' = 'A,' then publish to Child System A;

  • ELSE IF 'brand_identifier' = 'B',' then publish to Child System B;

  • ELSE IF 'brand_identifier' = 'C,' then publish to Child System C;

  • ELSE DEFAULT, publish to Parent system.

As you can see, Hierarchy Rules let you establish which Child systems have access, or a view, to which records in a given table, to which the Child system has been granted access.

Unique Child Data

A key risk to "shared" data across multiple Child systems is when more than one Child system has access to the same record, but values for a given field or set of fields from the record in question are specific to each Child system. This configuration could potentially create an issue where one brand overwrites the data provided by another brand.

To prevent this situation, the platform provides a field-level setting called "Unique Child Data." This setting appears on the Tables screen when you drill into a specific field. When this option is enabled for a field, and data is loaded directly into the Child system, none of the other Child systems will have visibility into that value. This feature allows you to store unique Child-specific values for a given field, or set of fields. 

Note: To use this Unique Child Data feature, the data must be loaded directly through the Child system, and not to the Parent system.

The Unique Child Data setting is often used in conjunction with Hierarchy Rules. By combining these features, along with the ability to configure the tables within the Parent / Child architecture at a very granular level, you can create a very complex, sophisticated architecture that allows you to isolate and share specific fields and  / or tables, as needed, in order to meet the your business requirements

Example

The following example illustrates the flexibility of leveraging the Unique Child Data feature.

Let's say you have four brands, each of which is set up within their own Child system within the Parent system. Three of these brands share a Product table that contains SKU level details, such as size, color, unit price, and so forth. All of these brands have tremendous cross-over in terms of the products they sell, but they sell those specific products at varying price points. For example, Brands A and B both sell the same red shirt. Therefore, both of these Child systems have access to the Primary Key for that item on the Product table. However, these two brands don't sell that red shirt for the same price. Brand A sells it for $19.99, and Brand B sells it for $24.99.

You could enable the "Unique Child Data" feature for the "Price" field on the Product table, thereby enabling you to define Child-specific values in this field. In this example, Brand A would store "19.99" in the Price field, and Brand B would store "24.99" in this same field. In both cases, you would have to load the Child-specific prices directly into the respective Child systems, and not to the Parent system.

Access

The Hierarchy Rules screen is accessible by the following method:

  • From the Main menu, select Data > Management > Hierarchy Rules

Create a New Hierarchy Rule

Copy a Hierarchy Rule

To copy an existing item to use as the basis for a new item:

  1. Search for the desired item (see Search for an Item for more details).

  2. Click on the item name. The main item screen is displayed and populated with the details of the selected item.

  3. In the Tool Ribbon, click Edit > Save As. A Save as dialog box is displayed.

  4. Enter a name for the new item.

  5. By default, the new item will be saved in the same folder location as the base item. Optionally, click the magnifying glass icon to browse to and select a different folder location.

  6. Click save a copy. The system creates a copy of the selected item.

View or Edit a Hierarchy Rule

To view or edit a Hierarchy Rule:

  1. When the screen is displayed, a list of all the current Hierarchy Rules is displayed in the left-hand side of the Workspace. Optionally, you can filter this list by typing in all or part of Hierarchy Rule name in the Search by Name field.

  2. Click on the Hierarchy Rule that you want to view. The Workspace is refreshed to show the details of the selected Hierarchy Rule.

  3. Optionally, to view detailed information about the Hierarchy Rule, click the Hierarchy Rule tab in the Tool Ribbon. The Item Details screen is displayed, showing who created the item, who modified it last, and what the last actions taken on the item were. On this screen, click Related Items in the Function Menu to see other items in the system that reference or utilize this Hierarchy Rule. When finished, click the Edit tab in the Tool Ribbon to return to the main edit screen.

  4. Optionally, you can assign one or more tags to your Hierarchy Rule. To assign a tag, click on the Add tag field in the Edit  section of the Tool Ribbon. The system displays a pop-up menu of all the existing tags. You can select one of these tags, or type in a new one and press Enter. You can repeat this process to add more tags. To remove a tag, click the X icon next to the tag label.  

  5. Optionally, to rename the Hierarchy Rule, click Edit > Rename in the Tool Ribbon. A Rename Item dialog box is displayed. Enter a new name for the Hierarchy Rule, then click save new name.

  6. Make any necessary changes to the Rule / System Pairs:

    • Add a New Rule / System Pair (see Create a New Hierarchy Rule above for details on how to create a new Rule / System Pair).  

    • If you need to rearrange the sequence of Rule / System Pairs, click on the grey section to the left of the row, and drag the entire row to its new location. Please note that you can't move the Default row.

    • If you need to remove a Rule / System Pair, click the remove button (X icon). The Rule / System Pair is grayed-out to indicate that it's been marked for deletion. To complete the removal, click Edit > Save in the Tool Ribbon.

    • If you need to delete the Default system, click the clear button (X icon) to the right of the Default row. The system deletes the system from the Default row.

    • If you need to edit a Rule / System Pair, click the edit button (pen icon). The Edit Rule screen is displayed. Make any necessary changes to the selected Filter or value. Make any necessary changes to the selected system. Click Edit Rule > Save Rule / System in the Tool Ribbon to save your changes and return to the Hierarchy Rule screen.

    • If you need to toggle to the other query type, click the corresponding button (match filter or match rule).

    • If you need to toggle to the other logical structure, click the corresponding button ("F> IF" or "IF > IF ELSE").

Note: If you toggle from one query type to the other, you'll be prompted with a warning message, telling you that any previously defined Rule / System Pairs will be deleted.

  1. In the Tool Ribbon, clickEdit > Save.

Delete a Hierarchy Rule

To delete an item:

  1. Search for the desired item (see Search for an Item for more details).

  2. Click on the item name. The main item screen is displayed and populated with the details of the selected item.

  3. In the Tool Ribbon, click Edit > Delete. A confirmation dialog box is displayed.

  4. Click delete item to confirm the deletion.

Foldered items are moved to the Recycle Bin. Non-foldered items are permanently deleted.