Working with Associations - Overview
This article is relevant to entity models that utilize the deprecated Visual Studio integration of Telerik Data Access. The current documentation of the Data Access framework is available here.
An association type (also called an association) is the fundamental building block for describing relationships in the Telerik Data Access Domain Model. Associations define relationships between persistent types in the domain model. Associations can only have two participating types, and each participating type in the association is known as an End (Source and Target). There can be multiple associations between types. Associations are represented on the design surface as a line that connects two persistent types.
An association definition contains the following information:
- Two association ends, one for each type in the relationship. An association end identifies the type on one end of an association and the number of type instances that can exist at that end of an association. Association ends are defined as part of an association; an association must have exactly two association ends. Navigation properties allow for navigation from one association end to the other. An association end definition contains the following information:
- One of the types involved in the association. For a given association, the type specified for each association end can be the same. This creates a self-reference association.
- An association end multiplicity indicates the number of type instances that can be at one end of the association. An association end multiplicity can have a value of one (1), zero or one (0..1), or many (*).
- Information about operations that are performed on the association end, such as cascade on delete. This is optional.
A navigation property is an optional property on an a persistent class that allows for navigation from one end of an association to the other end. Unlike other properties navigation properties do not carry data. A navigation property definition included the following:
- The association that it navigates.
- The ends of the association that it navigates.
The data type of a navigation property is determined by the multiplicity of its remote association end. For example, suppose a navigation property, OrdersNavProp, exists on a Customer persistent class and navigates a one-to-many association between Customer and Order. Because the remote association end for the navigation property has multiplicity of many (*), its data type is a collection (of Order). Similarly, if a navigation property, CustomerNavProp, exists on the Order persistent class, its data type would be Customer, because the multiplicity of the remote end is one (1).
The diagram below shows a domain model with two persistent classes: Product and Category. Between those two classes exist an association. The association ends for the Product-Category association are the Product and Category persistent classes. The multiplicity of the Category end is zero or one (0..1) and the multiplicity of the Product end is many (*), indicating that a category has many products and a product is part by zero or one category. Navigation properties, Category and Products, are defined. Note the data type of the navigation properties.
In this section:
- The Association Editor
- How to: Create One-to-Many Associations
- Using Default Join Table
- Using Custom Join Table
- Without a Join Table
- How to: Create One-to-One Associations
- How to: Create One-to-One Associations with Vertical Inheritance
- How to: Delete Associations
- How to: Create Constraints in Round-Trip Scenario