In any business application, there will be a number of situations where data elements are related in a many-to-many manner. For example, in a situation where a database holds data about products and their categories, if it is possible for the same product to belong in multiple categories and for each category to include multiple products, that implies a many-to-many relationship between the product table and the category table. To record such a relationship, there will typically be a "linking" table - a table that holds product IDs and their related category IDs. The linking table may include other information, too - for example, there may be valid date-ranges that a given product is available in a specific category. zeroCode automatically generates the pages that you could use to add one product to a given category and one category to a given product, but user-friendly applications demand that there be a page where, say, a user can assign the same product to multiple categories and, possibly, update the availability date-ranges for those categories at the same time. The zeroCode Relator helps you build exactly such a page in just a few clicks. When you build a Relator that has the first node as the product, say, with a Relator below it that has the category, the automatically-generated page includes product info and, below it, a set of check boxes that help you select specific categories and their date-ranges. Saving this page will cause the site to automatically make the appropriate entries in the product table (if the product node was in Add or Update modes) and the linking table...

Options in Relator construction include the ability to add linking information in a one-of-many kind of relationship (only one of multiple categories can apply to a product, for example)..

A Relator is thus a UDM that helps a designer establish a one-to-many relationship from a primary entity to a related entity. Typically, such relationships are depicted in a user interface via a single value for the primary entity and a table of check boxes for the related entity. Here are some descriptions of different types of relationships among tables and data in them.

One-to-Many relationship

This is a relationship between two tables in which a single row in the first table can be related to one or more rows in the second table, but a row in the second table can be related to only one row in the first table. A typical one-to-many relationship is between a list of publishers and the titles that they publish, whereby one row in a Publisher table can be related to several Title rows, but each Title can be related to only one Publisher.

One-to-One relationship
A relationship between two tables in which a single row in the first table can be related to only one row in the second table, and a row in the second table can be related to only one row in the first table, is a one-to-one relationship. This type of relationship is unusual, since the data in the two tables could be amalgamated into one table instead. An example of this kind of relationship is that between an Employee table and a Mailbox table used to store information about email addresses in a company. The tables have a one-to-one relationship because each employee has only one mailbox and each mailbox is assigned to only one employee.

Many-to-Many relationship
The Relator is most applicable in a many-to-many situation, as explained above. Consider the example shown. Here, similar to the products and categories example we considered above, we have FAQs assigned to specific types. The FAQTypes table has references to both FAQ and Type. IT he screen below shows page where a new FAQ can be entered and, simultaneously, be assigned to a set of Types. The type list comes from the Types table, while the data entered is inserted into the FAQ and the FAQ Types tables.