Data Spreading

Consider a family hierarchy that looks like this:

• Failure

  • Equipment Failure

    • Shutdown

According to this hierarchy, you could add records for all of the shutdowns to the Shutdown family. You would need to record data for those shutdown records such as Failure ID, Failure Date, and Failure Comments. To provide data storage for this information, you could put all four data fields in the Shutdown family.

Now, consider a hierarchy that looks like this:

>Failure

• >Equipment Failure

  • >Leak

    >Shutdown

For Leak records, you would need to record data such as Failure ID, Failure Date, Failure Comments, and Leak Substance. Note that three of these fields store the same type of data that you wanted to store for shutdowns. If the fields are all on the Shutdown family, you would have to recreate these fields for the Leak family. By using data spreading, however, you can create a streamlined database and avoid the duplication of effort.

Consider the following examples. Example A does not use data spreading. Example B uses data spreading.

Example A: No Data Spreading Applied

Family	Fields
Failure	None
Failure\Equipment Failure	None
Failure\Equipment Failure\Shutdown	Failure ID Failure Date Failure Comments
Failure\Equipment Failure\Leak	Failure ID Failure Date Failure Comments Leak Substance

Example B: Data Spreading Applied

Family	Fields
Failure	Failure ID Failure Date Failure Comments
Failure\Equipment Failure	None
Failure\Equipment Failure\Shutdown	None
Failure\Equipment Failure\Leak	Leak Substance

Example B, which uses data spreading, has only four fields as compared to the seven fields created for Example A. Also, Example B has no duplicate fields, whereas Example A has three duplicate fields: Failure ID, Failure Date, and Failure Comments.

Data spreading multiplied over hundreds of families can help save administrative time that is required to create and maintain the data fields, and it can help limit the size of the physical database.

Note: Only the field definitions are spread to lower levels. Values themselves do not spread.

In a data model that does not use data spreading, each record is stored in one row of one table, where the columns of that row contain all the information for the record.

In a data model that uses data spreading, however, the values for a single record are actually spread across multiple rows in multiple tables. Consider the following example, where spreading has been used.

Family	Fields
Failure	Failure ID Failure Date Failure Comments
Failure\Equipment Failure	None
Failure\Equipment Failure\Shutdown	None
Failure\Equipment Failure\Leak	Leak Substance

In this example, when you create a Leak record and define values for the Leak Substance, Failure Comments, Failure Date, and Failure ID fields, the only value that is actually stored in the Leak table is Leak Substance. The other three values are stored in the family table where the fields are defined (i.e., where the physical columns exist): the Failure table.

Each of the tables will contain a physical row, or record. When you view a record belonging to the Leak family, you are actually viewing a composite record that consists of the record stored in the Leak table and the record stored in the Failure table.

Typically, it is not necessary to refer to each record individually as a distinct row in separate physical tables. Therefore, in cases where spreading has been used, we use the term record to refer to the composite record that has been created as a result of data spreading.

There are three main aspects of field spreading:

• Metadata: When a field is spread from one family to another, the metadata (i.e., Field Identification Properties) associated with the root family field is inherited by the subfamily field when the subfamily is created. In other words, the field properties at the target level match the field properties defined at the source level. Most of this information cannot be modified on the family to which the field has been spread. The Caption, Description, and Help Text can be modified.
• Physical Tablespace: Within the family hierarchy, a table will be created for each family, regardless of its position in the hierarchy. Similarly, a column will be created within a subfamily table for every field in that family, regardless of whether or not it has been defined directly within that family or inherited from a higher-level family. In other words, even fields that are created through spreading will have their own physical tablespace in each family in which they exist.
• Rules: For field-level rules, you have two options. Within the subfamily, you can choose to:

  • Inherit the rules that are defined for the source family. This is the default condition for spread fields and is indicated by the Keep all properties of this field the same as they are in the Parent family option. When you accept this default selection, a code item will not be created for the field in the subfamily. All rules will be defined in the source family code item and applied to the subfamily.

    -or-

  • Define rules directly within the subfamily by selecting the Change the properties of this field for Child option. When you select this option, a code item will be created for the field in the field in the subfamily. The rules for the subfamily field will be defined directly in the subfamily code item. Any rules that exist in the associated source family code item will not be applied to the subfamily.

    Note: If a subfamily code item exists for a spread field and you change the rules setting back to inherit from the source family, the existing subfamily code item will not be deleted or modified but will no longer be used. In this way, if you later decide to define rules at the subfamily level, any rules that previously existed will already be there for you to use or modify as needed.

There are two ways to spread fields:

• Within the properties of any family field, select the Spread to subfamilies check box. When you do so, all subfamilies created under that family will automatically inherit that field when the subfamily is created. Spread fields will not be inherited by subfamilies that existed before the Spread to subfamilies check box was selected.
• Within any subfamily, use the Field Chooser to select fields in higher-level families that you want to create at the subfamily level. This option is useful for spreading fields to subfamilies that existed before a spread field was created. and for spreading fields only to some subfamilies.

After a field has been spread, clearing the Spread to subfamilies check box will prevent that field from being spread to additional families but will not remove the field from families to which it has already been spread. The metadata, physical tablespace, and rules will continue to exist at the subfamily level until they are deleted manually. Un-spreading a field will, however, break the connection between the source field and the subfamily field, meaning that changes made to the source family field will not be applied at the subfamily level, even if the subfamily field originated through spreading.