Read First: Relation, Place, Tuple Place relations are like places in that they specify the various aspects of a relation (participating types, participant cardinalities, tuple cardinalities, and role types). The difference is that place relations can have features in their own right. This happens by modelling the relation as it's own object type. For example, this is how the Marriage relation looks when it has no object type of its own:The above is the "unasserted" form of the relation that is represented in the meta-model using places. The relation can accept no user-defined features when it is in this form. This is how the Marriage relation looks when it has its own object type: A separate object type called Marriage has connections, namely the place relations, to its participating types. This is the "asserted" form. It can accept user-defined features, such as the connection to the city hall where the marriage is certified. The notation [p] is used in OOIE to mark the connections to the relation object type which are place relations. The place relations themselves in the above figure are "unasserted", that is, they are defined by places rather than by more place relations. This way, we break the infinite recursion that happens when a relation is modelled using other relations. If we need to add features to the place relations, we can repeat our technique by making them "asserted", that is, giving them place relations also. It's hard to think of an example of this for marriage, but click here for another example that has an asserted place relation. Of course, you can use places and place relations at the same time: The slash on the relation line between Man and Wife indicates that it is derived from the information in the place relation. We do this because place relations have more cardinality information than the original relation notation provides, so provide a source to derive the original relation. For example, the Marriage place relations could have different cardinalities, like this: The above cardinalities produce an unlikely model: everyone has a marriage license issued at birth, but it is not be filled out unless they marry. Nonetheless, the original relation cardinalities is perfectly compatible with such an interpretation. Here's an example where missing place relation cardinalities cause more confusion: You might try thinking of the various place relation cardinalities that might conform to this relation. Here's one: This means that people can make as many purchases as they like, but they must be made one at a time or at least recorded that way. Here's another: This means that people can make as many purchases as they like, and buy as many products as they like at each purchase. Here's yet another: This means that people can only make one purchase, but can buy as many as they like with that one purchase, as with a coupon. Tools implementing OOIE should ask users for the participant and tuple cardinalities even when modelling unasserted relations, because it is usually important information, even if they choose not to model it. If the user does not specify which interpretation of the system should adopt for the participant and tuple cardinalities, of leeway in interpreting cardinalities, OOIE recommends that implementation tools use these defaults: 1) Use the cardinalities on the original relation line (the relation mapping cardinalities) as the tuple cardinalities. 2) Use minimum 1, maximum 1, as the participant cardinalities. Tools should allow users to change the default cardinalities after they are assumed. Place Relations and Relations as Object Types Since relations are a kind of object type, features can be added to them as necessary by the user. Theoretically, features can be added to relations without defining place relations for them, however, OOIE requires place relations if the user wants to add features to a relation. This is so the diagrams show the connection between the relation object type and the participating types. Tools should enforce the above restriction even though the meta-model does not. If an OOIE implementation wants to give system-defined features to relations, which exist when the system starts up and are fixed thereafter, then it can do it without adding place relations. The requirement only applies to user-defined features. Place Relations Formally Formally, place relations link each tuple of a relation to elements of that tuple. For example, marriage has two place relations, one linking each marriage tuple (or certificate as it were) to the wife of that tuple, the other for linking it to the husband. So one end of the place relation is Marriage, which has tuples as instances; the other end of the place relation is the type of thing that can be in a particular "place" in the tuple, like Man or Woman. Place Relations Distinguished From Places And Role Types Place relations can be mistaken for places and roles types, because they distinguish the elements of a tuple according to the role the element plays in the tuple. For example, the WifeOf/IsWifeOf place relation points out the wife of the marriage. However, the place relation does not specify the types Wife and Husband, only Man and Woman. Formally, the role type is the subset of a participating type which has the instances actually used in a certain place of some tuple at any given time. For example, the Husband role type is the subset of Man containing the men that are married. Summary of Relations In ordinary language, it is easy to confuse the various parts of a relation because we use the same name for parts that are semantically different. For example, we say a marriage has a wife which is the mapping from a marriage to a woman (a relation mapping of a place relation), but we also say that a particular woman is a wife meaning that she is classified under the role type Wife. Or we refer to the husband of a married woman which is the mapping from the wife element of a marriage tuple to the husband element (a relation mapping), but we also say that a husband is in a marriage which is a mapping from a man to marriage (a relation mapping of a place relation). One can imagine the difficulty implementors face when requirements are modelled without the above distinctions. To clarify the various aspects of a relation, the Marriage relation is presented below with the various aspects separately labelled. The figure shows some of them, and the listing afterwards. The places and relation mappings are listed first, because this is the common case of an unasserted place relation, then the place relations are described to a recursion depth of one. 1) Places a) Wife Place i) Participating type : Woman ii) Participant Cardinality: min 1, max 1 iii) Tuple Cardinality : min 1, max 1 iv) Role type : Wife b) Husband Place i) Participating type : Man ii) Participant Cardinality: min 1, max 1 iii) Tuple Cardinality : min 1, max 1 iv) Role types : Husband 2) Relation Mappings: a) Husband Of Woman i) Domain : Woman ii) Range : Man iii) Image : Husband iv) Co-image: Wife b) Wife Of Man: i) Domain : Man ii) Range : Woman iii) Image : Wife iv) Co-image: Husband 3) Place Relations: a) Linking Marriage and Wife i) Places (1) Marriage Place (a) Participating type : Marriage (b) Participant Cardinality: min 1, max 1 (c) Tuple Cardinality : min 1, max 1 (d) Role type : Marriage (2) Wife Place in Place Relation (a) Participating type : Woman (b) Participant Cardinality: min 1, max 1 (c) Tuple Cardinality : min 1, max 1 (d) Role type : Wife ii) Relation Mappings: (1) Wife Of Marriage (a) Domain : Marriage (b) Range : Woman (c) Image : Wife (d) Co-image: Marriage (2) Marriage Of Woman (a) Domain : Woman (b) Range : Marriage (c) Image : Marriage (d) Co-image: Wife b) Linking Marriage and Husband i) Places (1) Marriage Place (a) Participating type : Marriage (b) Participant Cardinality: min 1, max 1 (c) Tuple Cardinality : min 1, max 1 (d) Role type : Marriage (2) Husband Place in Place Relation (a) Participating type : Man (b) Participant Cardinality: min 1, max 1 (c) Tuple Cardinality : min 1, max 1 (d) Role type : Husband ii) Relation Mappings: (1) Husband Of Marriage (a) Domain : Marriage (b) Range : Man (c) Image : Husband (d) Co-image: Marriage (2) Marriage Of Man (a) Domain : Man (b) Range : Marriage (c) Image : Marriage (d) Co-image: Husband Read First: Relation, Place, Tuple
Subtypes: None