Multiplicity in Visual C#

Encode QR in Visual C# Multiplicity

The multiplicity of a relationship refers to the number of participants at either end of the association. In the Entity Framework, an association s multiplicity determines the nature of the navigation properties that represent the relationship.

In the Entity Framework, there are always two ends to an association, regardless of the multiplicity. For example, we have customers at one end of a relationship and orders at the other end. The multiplicity describes how many items may be at a particular end, not how many ends there are. You will sometimes want to represent more complex relationships for example, a so-called ternary relationship involves three kinds of parties. This is a different concept from multiplicity and is called degree. For example, consider a teaching arrangement in a college, where a student is taught a subject by a teacher; this relationship involves three entities (student, subject, and teacher). These higher-degree relationships are typically modeled in the database by having a table just for the relationship itself. Likewise, the EDM does not directly support relationships with a degree of more than two, so you would represent such a relationship with a distinct entity type in the conceptual model, adding associations between that entity and all the participants in the relationship.

For each end of a relationship, you can specify a multiplicity of either 1, 0..1, or *. The first, 1, means what it says there is always one item at that end of the association. The last, *, means any number there can be zero, one, or several items at that end. A multiplicity of 0..1 means zero or one this indicates that the association is optional, but where present, there is just one entity at this end. In a one-to-many relationship, the two ends have a multiplicity of 1 and *, respectively. You can see this in Figure 14-2 the lines between entities represent associations, and the multiplicity appears at each end of the line. So an item at the first end can be related to any number of items at the second end; an item at the second end is always related

to exactly one item at the first. In C#, the entity at the 1 end would have a navigation property that offers a collection, in order to provide access to the many end. The entity at the * end would provide a simpler noncollection property to get back to the one entity it is related to. A variation on this theme has 0..1 instead of 1 at the first end, and * at the second end as before. This is similar to a one-to-many relationship, except items at the many end don t necessarily have to be related to an item at the other end. For example, you might want to represent the relationship between managers and their reports. But if you go far enough up the corporate hierarchy, you will find someone who has no manager the navigation property would return null. So a simple one-to-many relationship doesn t work here you would need 0..1 instead of 1 at the manager end of the association. Sometimes one-to-one relationships crop up each item at one end is always related to exactly one item at the other end. This is an unusual kind of relationship because it implies that entities are inextricably and exclusively linked. Relationships that sound like they might be one-to-one are often not. Here s an illustration from popular culture, describing a relationship between a master and an apprentice expressed as: Always two, there are. No more, no less. A master, and an apprentice. A master always has an apprentice, an apprentice always has a master, so isn t that a one-to-one relationship In fact, this might need to be a one-to-many relationship because on the death of an apprentice, the master takes a new apprentice. (The apprentice has just one master, as the only career paths are promotion to master or untimely death. So we can at least be sure that this is not a many-to-many relationship.) The constraint expressed here is merely that the master has a one-at-a-time approach to relationships, much like serial monogamy. (For example, both Darth Maul and Darth Vader were apprentices of Darth Sidious.) So if the database needs to reflect the full history rather than just the current state, a one-to-one relationship won t be sufficient. (Although if you only need the database to store the current state, one-to-one might be fine here.) In databases, oneto-one relationships often exist because information about a single entity has been split across multiple tables, perhaps for performance reasons. (The EF lets you map this back to a single entity in the conceptual model, so such relationships are likely to be more common in the store schema than the conceptual schema.) Variations on one-to-one where one or the other end is optional can be useful. For example, you might have an entity representing a customer and an entity representing an account. An organization (such as a butcher shop) might choose to have a policy where customers are not required to have accounts, but where accounts are held any single customer can have only one account, and accounts must be held by exactly one customer. (That s not the only imaginable policy, of course.) The relationship between

Yoda discussing Sith terms of employment, from Star Wars Episode I: The Phantom Menace. Opinion is divided on whether this variant can still be called one-to-one. Strictly speaking it s incorrect, but in practice you ll see one-to-zero-or-one relationships widely described informally as one-to-one.

a customer entity and an account entity would have a multiplicity of 1 at the customer end and 0..1 at the account end. Finally, there are many-to-many relationships. For example, you might have an entity type to represent a standard part such as an M3 bolt, and an entity to represent a part manufacturer. Many manufacturers are capable of producing M3 bolts, and most manufacturers produce more than one kind of product. To model the relationship of who produces what in the EDM, you could use an association with a multiplicity of * for both ends of the association. And in code, both entities would have navigation properties offering collections of objects. However, there s an issue with many-to-many relationships in the EF. In the database, such a relationship is represented as a separate table, where each row contains two foreign keys, one for each end of the relationship. If that s all the table contains, the EF will happily let you map this table to an association in the conceptual model, and the navigation properties will work as described. However, if the table contains other information, you will end up needing to represent it as an entity in its own right. For example, given the product/manufacturer example earlier, it might turn out to be useful to know what product code a particular supplier uses for a particular standard product. There s no place for this information to go if you just have navigation properties on the product and manufacturer that point to one another you would need an extra entity type to hold this property that is specific to a particular product/manufacturer combination. This can get slightly awkward when there are columns in the relationship table that your application doesn t particularly care about, but which the EF insists are mapped because they are nonnullable and don t have default values. Your conceptual model would not be able to represent this table as a simple many-to-many association, because that would leave nowhere to map the relationship property. (The underlying issue here is the same one that prevents you from omitting certain database columns from your entities.) Finally, we ll look at one more feature of the Entity Framework s mapping capabilities: support for inheritance.