Overview of Relationships

Third normal form

USoft Developer assumes that your data model is in third normal form. Such a model contains 1:m relationships and 1:1 relationships between objects but no n:m relationships. If your data model contains n:m relationships, you must define a new table with the primary keys of these two tables as columns. Then, you can define the 1:n and 1:m relationships to other tables.

Relationships always involve one or more columns from two tables. A relationship may exist between two different objects, or an object may have a relationship with itself. Relationships can be expressed in ordinary language. For example, "a table has columns" or "a column is part of a table". The table in which the contents of these columns are actually defined is called the parent, a table that references the parent is called a child. The predicates (e.g. "has", or "is part of") that are used to describe the relationships are called "role" and "co-role" respectively. The role describes the relationship from the point of view of the parent: for example, "a guide guides a scheduled tour". The co-role describes the relationship from the point of view of the child, for example "a scheduled tour is guided by a guide".

By default, USoft Developer generates a separate window for each database object. If you define a mandatory relationship between two tables, the parent window will include the child. The menu line that is associated with a relationship will automatically appear on the Related List menu, and on the Related Windows List

When you define relationships between tables, you have to specify rules that govern USoft Developer's behavior when the end-user tries to update or delete a parent object that has children. Are these manipulations forbidden, or do they cascade onto the table's children?

NOTE 1:

When you define the table and column structure of a child table, remember that it must contain ALL the primary key columns of its parent.

NOTE 2:

A special case is formed by a relationship in which the foreign-key columns are not mandatory in the child but in which the primary key columns are mandatory in the parent. In such a case, the foreign key will not be validated in the child until all foreign-key columns have been filled. Suppose, for example, that a parent has a concatenated primary key with three mandatory columns, but that none of these columns are mandatory in the child. If only two of the foreign-key columns have been entered in the child, the foreign key will not be validated.