It is a standard practice to equip a engine model with multiple application views, each with the purpose of managing a subset of the data domain; from each view you omit the parts of the engine model that are not strictly necessary or that you want to hide from certain groups of users.
Restricting access to certain engine model elements effects the so-called vertical partitioning of data; this is done by modifying their manageability, that is, by defining which database elements are managed in each application view by enabling or disabling classes, attributes and roles in the relevant Application Schema.
You can disable an item by clicking on it when the Toggle management policy is selected in the Palette.
Depending on the structure of the engine model, disabling an element involves all the elements that depend on it; for example, when we disable a class (by clicking on the circle at the top, i.e. its default class role), along with it all its attributes and roles for which it is parent are disabled, along with any part classes, unless the latter participate in other relationships.
In the Designer, when an element is disabled it is colored gray. In the second image of the following example we can see that some attributes have been disabled.
All elements are enabled; one of the two roles of Product_component is disabled because the relationship is unidirectional.
Some attributes have been disabled in the Product and Ingredient classes.
You can re-enable a disabled element by clicking on it while the is selected. The only case where this is not possible is for outgoing roles in a unidirectional association, which by nature are always disabled (more information is available further on).
If an element is disabled in all application views, the Designer warns us by showing a issue; it makes little sense to model data that cannot be accessed in any way. The operation is allowed, however, and the warning is not blocking.
The Designer enforces certain constraints that prevent you from generating inconsistent application views.
Disable attributes #
A disabled attribute cannot be selected or manipulated through GraphQL queries involving its class.
When working with derived attributes, not all elements used to calculate a math or a query need to be visible in the application, especially if they are derivatives created solely for use within the expression editor; in such cases, it may be useful to disable these intermediate derived attributes, so that only the most relevant information is shown to the user.
Place the cursor over an attribute and click on it when the Toggle management policy appears.
Disable roles #
Enabling roles depends on the navigability rules of the relationship defined in the Database Schema. The outgoing roles in the unidirectional associations are therefore always disabled.
In the example shown in the figure, the outgoing role from Employee is disabled because the association between the two classes is unidirectional towards Qualification (it is not possible to view the list of employees associated with each qualification).
Place the cursor over a role and click on it when the Toggle management policy appears.
Disabling classes #
By disabling the default class role of a class, the user of that view will lose the ability to manage that class.
Place the cursor on the class role of a class and click on it when the Toggle management policy appears.
Disabling a default class role is not necessarily the same as completely hiding a class from the application view; in fact, if the disabled class is involved in one or more relationships, and the incoming roles are enabled, the class will remain reachable by other classes pointing to it. In the Designer, only the default class role will appear colored in gray, while the class and its attributes will remain colored in yellow. To completely disable a class, it is necessary to disable all the roles that point to it.
In the example shown in the figure on the left, the class role for Ingredient has been disabled. As a result, it cannot be accessed via GraphQL. However, even if there is no direct access point to this class, it is still possible to see its objects: queries on Product_component will still be able to show all the associable objects present in the Ingredient class. To avoid this, you need to disable the incoming role as well, as shown in the image on the right.
Only the default class role is disabled
Association role is also disabled
Disable part classes #
In a composition a part class does not have a default class role, since by definition an object of that class exists only as part of an object of the whole class. Disabling the whole class will also disable the part class, but disabling the role that points to the part class will hide the part class.
Disabled whole class
Disabled part class