ComponentOne DataObjects for .NET
Creating and Modifying Composite Table Diagrams
DataObjects for .NET (Enterprise Edition) > Schema Objects > Composite Tables > Creating and Modifying Composite Table Diagrams

To create a composite table, press the Add button or click the drop-down arrow next to the Add button and selectComposite Table from the context menu in the Tables window.


The empty new composite table will open as a new Composite Table Editor page. The Composite Table Editor has two tabs: Diagram and Properties.


The Diagram tab contains the diagram (graph) of constituent simple tables connected with relations. It also allows you to set properties of the graph's nodes, table views (CompositeDefView objects), and of the graph's arcs, view relations (CompositeDefRelation objects). The Properties tab consists of two panes: the upper pane showing the composite table properties and the lower pane showing the composite table fields and their properties.

Immediately after creating a new composite table, it should be renamed by setting its Name property in the Properties tab or by renaming the composite table node in the Tables window.

Setting up a composite table starts with adding some simple tables to its diagram. Tables can be added to the diagram by clicking the Add tables button in the Diagram of the Composite Table Editor. The Add tables dialog box appears.


Select tables from the list of Existing tables and use the arrows to move them to the list of Selected tables.

Table can also be added by dragging and dropping them from the Tables window onto the Diagram in the Composite Table Editor. When you add a table view to the diagram, relevant relations connecting it to other table views in the diagram are also added, unless suppressed by unchecking the "Create view relations" check box in the Add tables dialog box or by unchecking the "Automatically create relations adding tables to diagrams" check box in the Options dialog box (select Optionsin the Schema menu). Redundant relations can then be deleted by selecting a relation arrow in the diagram and pressing the Delkey or by right-clicking it and selecting Remove from the context menu.


You can also add tables to the diagram using the Table button on the top bar of the Diagram tab, but then you will have to set the Table property manually, selecting the newly created table view (a CompositeDefView object) and setting its Table property in the property grid below the diagram.


It is also possible to add relations to the diagram manually. Press the Relation button on the top bar of the Diagram window and draw an arrow connecting parent and child tables using a drag-and-drop operation from parent to child. The Schema Designer will try to find an appropriate relation connecting these two tables (inverting the relation, if necessary). When the new view relation is created, select it and look at popup box or the value of the Relation property in the property grid below the diagram. If this property is empty, it means that the Schema Designer could not find an appropriate relation.


The objects shown on the diagram are CompositeDefView and CompositeDefRelation objects.

A table view (CompositeDefView object) represents a table, determined by its Table property, as a part of a composite table, as well as properties of its own. CompositeDefView properties in a composite table diagram can be used to override simple table properties. For example, you can set ReadOnly to True. This will make this table a read-only part of the composite table, although the simple table itself may be modifiable. The following CompositeDefView properties override Table properties: AllowAddNew, AllowDelete,and ReadOnly.

A composite table can contain multiple table views based on a single table. In other words, a simple table can occur several times in a composite table diagram. Although it is not common, this is sometimes useful to represent relations of a table with itself, what is called "self-joins" in SQL, as in Employee1.SupervisorID = Employee2.EmployeeID, where Employee1 and Employee2 are both aliases for the same table Employee. This feature is fully supported in composite tables, with a single restriction that if this table duplication occurs on the last level (the last table that is a child in a one-to-many relation is duplicated somewhere else in the same diagram), then adding new records to the composite table is not allowed, since it would lead to abnormal results.

A CompositeDefRelation object represents a relation, determined by its Relation property, as a part of a composite table diagram, an arc in the graph. The CompositeDefRelation class is derived from ViewRelation. Only simple relations can be used in a composite table diagram, its CompositeDefRelation objects cannot be based on composite relations.

Note: General ViewRelation objects can be based on any relation. For more information, see View Relations.

A view relation, as an arc in a composite table diagram, can have direction opposite to the direction of the relation on which it is based. For example, having a one-to-many relation Customers – Orders, we can create a many-to-one view relation Orders – Customers, based on Customers – Orders, but in inverse order (direction). So, if the Relation object Customers – Orders has Parent = Customers, Child = Orders, the view relation, if inverted, will have Parent = Orders, Child = Customers. This inversion does not change the original Relation object. The usual practice is to define all simple relations, Relation objects shown in the Relations window as one-to-many, and then apply them in diagrams, create view relations based on them, in direct (one-to-many) or inverse (many-to-one) order. To invert a view relation, right-click the relation in the diagram and select Invert from the context menu.


A CompositeDefRelation object has a number of properties in addition to the properties Relation, Parent and Child that determine the relation it represents and in which direction, direct or inverse, it is applied. In addition to that, it only has a read-only Cardinality property, returning OneToMany or ManyToOne according to the relation's Cardinality and the direction (if inverse, Cardinality is inverted), and the OuterJoinInManyToOne property affecting the process of generating SQL for data fetch. For more information, see How Composite Table Data is Fetched, Stored and Updated.