- DDO Structure Editor rootThe first root item in the Data Dictionary Object (DDO) Explorer's treeview comprises the DDO Structure Editor.
The data dictionary structure is displayed in a tree. This display is designed to present all the information required to create and review a DDO structure.
Each table in the DDO structure is presented in the first level of the list. Since access to each table is wrapped in a data dictionary object, the names of these data dictionary objects are shown.
By expanding a table in the list, you can see a list of all DDO server-to-server connections (displayed in the child table), and any child-to-parent constraints.
Different elements of a DDO structure are represented by different icons in the tree. Below is a list of the different element types and their icons:
- DDO Structure Editor root
- Table (DDO)
- Table (Main DDO)
- Server DDO
- Constrain to table
The DDO Structure Editor supports various operations though it's Context Menu.
Before creating a DDO structure, you should make sure that your data dictionary subclasses have been created for each table, and that they are proper. In particular, you want to make sure the expected server-to-server connections are properly defined in your data dictionary classes. Each data dictionary class should contain a list of expected server (parent) data dictionaries and a list of client (child-table) data dictionaries. (Use Data Dictionary Modeler to create the data dictionary classes for each table in your database).
The Studio will analyze your data dictionary subclass and use these required connections to determine how a DDO structure should be connected.
Related Topics: Data Dictionary Table Structures
Each component that binds to data from a table should be assigned a main DDO. This is the focal point for database operations that are performed in this component.
In some cases, the main DDO will be the child-most table in a relational structure (e.g., an Inventory main data dictionary with a Vendor parent).
In other cases, the main DDO will be in the center of data dictionary structure (e.g., an Order Header main DD with a Customer parent DD and an Order-Detail child DD).
When a main DDO has child-table DDOs, these children are almost always constrained to the main data dictionary (e.g., the Order Detail can only show records that are related to the current Order Header). The Studio uses this knowledge to determine how child/parent constraints should be enforced. When a main DDO is assigned or changed, the child/parent constraints in the DDO structure are reassigned.
A general rule of thumb in determining the Main DDO for a component is to ask: what is the main data processing purpose of the component? e.g. For a customer maintenance view, the customer DDO is the main DDO. For an order entry view, you want to display one order header at a time; you also want to display only order details relating to the current order header. This means that the Order Header table will be the main DDO.
You are encouraged to use this as a learning tool. In particular, watch how changing main DDOs alters the child/parent constraints. When you can predict how the changing of the main DDO will change constraints, you have mastered an important concept. Create different structures and look at the source code that is generated. Finally, look and see how data entry control server assignments are made (the server property). The use of direct and indirect (from a parent container) server assignments and the fact that servers are not assigned based solely on the table & column value of a control is a source of potential confusion. Study how the Studio does this.
DDO Structure Editor Context Menu