The terms used by the persistence system are largely based upon the Unified Modeling Language (UML) terminology. For background information, please consult the UML documentation at http://www.rational.com/uml/.
Associations are bi-directional semantic connections. Put another way, they represent the relationship between two separate objects (UML Classes). Objects within an association are completely independent, though they may be linked together. Data may be passed in either or both directions, and more than one association may exist between two classes. In UML diagrams, associations are represented as links (lines between the two objects).
An example of an association is the relationship between a user and a group. From the level of object modeling, the two classes involved are User and Group and there is a many-to-many association between them. In this case, the association is one of membership. That is, a user "is a member of" a group.
See Also: Composite.
Attributes are data fields that represent some property of the containing object that is shared by all instances of the object's class. Attributes normally have names (e.g., "Address") and Types (e.g., "String" or "Boolean"). An example of this would be the "Address" of a "User."
See Also: Property.
A Composite Relationship (also known as a "Composition") is a special kind of association in which one class cannot exist without another. That is, the object strongly owns its parts and if the object is deleted, its parts must also be deleted. The multiplicity at the parent object end must be 1..1 or 0..1. An example of a composite relationship is a key with a keyboard. The key is useless without the keyboard; if you remove the keyboard, you are also removing the key. Composite associations are useful for modeling relationships between objects where a contained object cannot exist outside its container object.
An example specific to the WAF is the composition between Parties and WAF Objects. A Party cannot exist without the corresponding WAF Object. If the WAF Object is deleted, the Party must also be deleted. The multiplicity holds because each Party has exactly one related WAF Object.
See Also: Association.
Derived Associations are exactly like Associations, except that they have one or more levels of indirection. That is, if A is associated with B, and B is associated with C, then A has a Derived Association with C.
See Also: Association.
A Data Object is any persistent entity within a relational database that is exposed to the applications as an object. An example is a row within the "users" table. It is important to realize that Data Objects are not the same as Domain Objects, and that they actually have a many-to-many relationship. See Section 9.2 Beginning With Data Objects and for more information.
See Also: Domain Object.
Domain objects are not part of the persistence layer, but since they are the most common way to access a Data Object (which is part of the persistence layer), it is useful to discuss them here. Domain objects contain logic particular to a business domain, such as managing users or credit cards. This logic operates over a persistent data object that contains the state necessary to implement the domain-specific logic. Domain objects contain the application logic specific to the domain that requires representing persistent state. It is important to realize that Domain Objects are not the same as Data Objects. Domain Objects and Data Objects have a many-to-many relationship with each other. See the Section 10.2 Domain Objects Tutorial for more information
See Also: Data Object.
Filters are used to allow developers to restrict the results returned by a Data Query or the results represented in a Data Association or Data Collection.
A Join Element is a single part of the larger Join Path. It is used to indicate how two tables can be joined to each other. In the following example, there are 4 Join Elements that make up 2 Join Paths. The first Join Element is in the form join foo and the second one is in the form of to bar.
association {
Article[0..n] articles = join magazines.magazine_id
to magazine_article_map.magazine_id,
join magazine_article_map.article_id
to articles.article_id;
Magazine[0..n] magazines = join articles.article_id
to magazine_article_map.article_id,
join magazine_article_map.magazine_id
to magazines.magazine_id;
} |
See Also: Join Path.
A Join Path is the collection of Join Elements seperated by commas and indicate how to join tables to each other. They are typically used within associations to indicate how the objects within the database are related.
In the following example of an association between Articles and Magazines, there are two Join Paths; the first one is in bold and the second is in italics.
association {
Article[0..n] articles = join magazines.magazine_id
to magazine_article_map.magazine_id,
join magazine_article_map.article_id
to articles.article_id;
Magazine[0..n] magazines = join articles.article_id
to magazine_article_map.article_id,
join magazine_article_map.magazine_id
to magazines.magazine_id;
} |
A Link is the path from one object to another. Associations are types of links. A Link Attribute is a property of this link. For instance, if a developer wanted to know when the link was created, he could store the creationDate as a Link Attribute.
See Section 9.3.4 Link Attributes and Section 9.8 Link Attributes.
See: Roles
Multiplicity refers to a set of values (all non-negative integers, plus infinity) that can be used to describe cardinality. PDL uses a Multiplicity to specify the relationship between objects within Associations. Specifically, it can be used to answer the question, "given an object of type A, what is the range of number of objects of type B that can be related to A?" The syntax used is "[#..#]" where # is either "0", "1", or "n". The valid multiplicities are "[0..1]" (there may or may not be a single associated object), "[0..n]" (there may be zero to n associated objects), and "[1..1]" (there is always exactly one object related to the given object). The Multiplicities with an upper bound of "n" are typically used when there is a mapping table involved. The Multiplicity of "[1..1]" is typically used when there is a non-null, single column in the table referencing another table. If no multiplicity is specified, "[0..1]" is used as the default.
Within the persistence system, Property is used as the global term to describe either an attribute or an association of an Object Type.
The Reference Key provides the Metadata Driven SQL system information about how to join the current Object Type with its super Object Type. In a standard Object Type that does not extend anything, an Object Key is declared to uniquely identify the object within the tables. If an Object Type extends another Object Type, a Reference Key is used instead of an Object Key. This Reference Key holds information about how the table of the child type can be joined with the table of the super type. For an example, see Section 9.2.6 Object Type Inheritance.
If the Object Key of the parent is keyed off of multiple rows, the columns in the reference key must appear in the order in which they should be joined. For instance, the definitions below will produce the join syntax that follows them (remove the "\" and make it all one line).
model tutorial;
object type FirstObjectType {
<Attributes defined here>
object key (object_id_one, object_id_two);
}
object type SecondObjectType extends FirstObjectType {
<Attributes defined here>
reference key (secondtable.second_object_id_one, \
secondtable.second_object_id_two);
}
The above PDL would produce SQL join code similar to the following:
<select code and tables here>
where secondtable.second_object_id_one = firsttable.object_id_one
and secondtable.second_object_id_two = firsttable.object_id_two |
See Also: Object Key.
Roles describe how one class is associated with another. One or both classes in the association may have roles. For example, a User has a "Member" role for the group (that is, a user is a member of a group).
See Also: Role Reference.
Role Reference is the term used to describe an object type's reference to another object type. It is similar to having an attribute with an Object Type modifier instead of a Java type. See Section 9.3.3 Role References and Section 9.3.5 Using Java to Access Associations for more information.
See Also: Property.
Metadata Driven SQL is the term used to describe SQL that is automatically generated by the persistence layer. The persistence layer is able to generate statements to perform insert, update, and delete, and it selects from the database if it is given enough information about the object (e.g., information about how attributes map to database columns and how tables can be joined together). In addition, it is able to use the object type metadata to generate DDL statements that can be used to create an update the actual table definitions.
The Object Key allows the persistence system to uniquely identify a particular Data Object for a given Object Type. Specifically, the Object Key column(s) of an Object type is similar to the "primary key" of a database table.
If a particular object has a multi-key primary key, it should have a multi-key Object Key as well. To do this, you can simply separate the attributes by commas. For instance, for a mapping table whose primary key contains the columns object_id (whose attribute is id) and site_node_id (whose attribute is siteNodeID), the object key would look like object key (id, siteNodeID). This is not a strong example, however, because in the common case mapping tables should not be represented as object types. Rather, they should be used in join paths when defining associations.
For more information, see the Section 9.2.3.3 Object Key section of the PDL tutorial.
See Also: Reference Key.
The Persistence Definition Language has been created to provide developers with a syntax to specify data objects, their associations, and how the information is stored in the database. The files specified in PDL and SQL are the only files that contain actual SQL and thus are the only files that must be changed when porting the system to a new database.
A UML Class is a description of a set of objects that share the same attributes, operations, and relationships. A UML Class is almost identical to a Java class.