The difference between flattening attributes and traversing the object graph (either programmatically or by using key paths) is that the values of flattened attributes are tied to the database rather than the object graph. If an enterprise object in the object graph changes (for example, because a user changed a value in another part of the application), a flattened attribute can quickly get out of sync. For example, suppose that you flatten a deptName attribute into an Employee object. If a user then changes the employee's department reference to a different department or changes the name of the department itself, the flattened attribute won't reflect the change until the changes in the object graph are committed to the database and the data is refetched. However, if you're using key paths in this scenario, a user of your application sees changes to data as soon as they happen in the object graph. This ensures that your application's view of the data remains internally consistent.
Therefore, you should only use flattened attributes in the following cases:
To flatten an attribute:
For example, to add the name of an actor to MovieRole, you can traverse a talent relationship (which represents MovieRole's relationship to Talent) and add the actor's last name (lastName) to MovieRole as a flattened attribute. This is a contrived example, because in this case it would be better to use a key path than to flatten an attribute.
Figure 30. Adding a Flattened Attribute
Alternatively, you can use the button in the toolbar.
The derived attribute (in this example, talent_lastName) appears in the list of properties for MovieRole. The format of the name reflects the traversal path: the attribute lastName is added to MovieRole by traversing the talent relationship.
Figure 31. Examining a Flattened Attribute in the Attribute Inspector
In the Attribute Inspector, the pop-up list to the left of the Definition field identifies the attribute as "Derived".
The Definition field (the second text field from the top of the Attribute Inspector) must accurately reflect the attribute's external name and the table in which it resides. For example, if you edit its text to be "Name" and change its mode to "Column," it no longer maps to an existing attribute. In other words, only edit this field if you are sure you can predict the outcome.
To display this flattened attribute, use the Data Browser.
To select multiple, non-contiguous attributes in the Model Editor on Windows NT, hold down the Control key while you click on each attribute. On Rhapsody, use the Shift key.
Figure 32. Using the Data Browser to Check Your Model
Table of Contents Next Section