Object-RelationshipsThe ]project-open[ Data-Model , Frank Bergmann, 2010-09-22

This tutorial explains how to create generic relationships between OpenACS/]project-open[ objects.

Such relationships include the “is-member-of” relationship between users and business objects, but also relationships like “is-employee-of”, “is-invoice-for”, “is-group-member-of” etc.

]project-open[ 2010, Data-Model / Frank Bergmann / 2

GUI Example

The screenshot at the right shows the list of “members” of a project.

Please note the “%” column that represents a parameter of the “is-member-of” relation between the user and the project.

OpenACS/]project-open[ comes with a built-in mechanism to model such types of relationships.

]project-open[ 2010, Data-Model / Frank Bergmann / 3

Types of Relationships

1:N Relationships:Example: Every project should have exactly one customer. Such relationships are usually modeled as a database column in the 1: object (for example: The "customer_id" field of a Project)

N:M Relationships:Example: One user can be member of many projects, companies etc. Such relationships are usually modeled using an "acs_rels“ relationship.

CompanyOther

Company

User

Project

OtherUser

is_c

ust

om

er

(1:n

rel)

is_member

is_member

(project manager)

is_member

is_friend

(Sample N:M Relationships between a user and several ]po[ objects)

]project-open[ 2010, Data-Model / Frank Bergmann / 4

rel_type

object_id_two

rel_id

acs_rels

object_id_one

The acs_rels Table

The acs_rels table contains is basically a “mapping table” with two columns:

– object_id_one – the “from” field

– object_id_two – the “to” field However, relationships are

“objects”, so the rel_id field references the “acs_objects” table as every ]po[ project (see the “Object Relational Mapping” section).

rel_type is redundant/denormalized and identical to acs_objects.object_type.

The fact that a relationship is an object allows us to sub-type acs_rels and to create custom relationships.

SELECT p.project_name,im_name_from_user_id(u.user_id) as

user_nameFROM acs_rels r,

im_projects p,users u

WHERE r.object_id_one = p.project_id andr.object_id_two = u.user_id

project_id

im_projects

project_name. . .

project_nruser_id

user

. . .username

(A sample SQL query to list all user-project memberships)

The acs_rels table is essentially a generic mapping table for acs_objects. Once we come up with a way to associate attributes with relationship types, we could replace many of the ACS 3.x mapping tables like user_content_map, user_group_map, and user_group_type_modules_map with this one table. Much application logic consists of asking questions like "Does object X have a relationship of type Y to object Z?" where all that differs is X, Y, and Z. Thus, the value of consolidating many mapping tables into one is that we can provide a generic API for defining and querying relationships. In addition, we may need to design a way to enable "type_specific" storage for relationships (i.e., foreign key columns for one-to-many relationships and custom mapping tables for many-to-many relationships), instead of only supporting "generic" storage in the acs_rels table. This would parallel what we do with acs_attributes.

]project-open[ 2010, Data-Model / Frank Bergmann / 5

Relationship Types

object_idobject_type

acs_objects

rel_id

im_biz_object_members

object_role_id

rel_id

acs_rels

object_id_oneobject_id_two

rel_type

rel_id

membership_rels

member_staterel_id

admin_rels

rel_id

composition_rels

rel_id

group_rels

rel_typegroup_id

rel_type

acs_rel_type

object_type_tworole_one

object_type_one

role_two

min_n_rels_onemax_n_rels_onemin_n_rels_twomax_n_rels_two

Generic (“abstract”) relationship class

Concrete group relationship

Concrete ]po[ membership

percentage

]project-open[ 2010, Data-Model / Frank Bergmann / 6

Range and Domain Constraints

In order to maintain a kind of “referential integrity” it is possible to specify constraints on Domain and Range of a relationship:

– Domain Constraint:Limits the type of object_id_one

– Range Constraint:Limits the type of object_id_two

Example: Our ]po[ “member” relationship (“im_biz_object_member”) specifies a range constraint of “person”, effectively enforcing that only “persons” (or its sub-types “user” etc.) can be a member of a ]po[ business object.

It is also possible to specify constraints on the cardinality of domain and range. However, this is currently not used in ]po[.

Object 1 Object 2relationship

Domain(Example: Person)

Range(Example: Project)

(Relationship can be constraint to specific Domain and Range for consistency checking)

rel_type

acs_rel_type

object_type_tworole_one

object_type_one

role_two

min_n_rels_onemax_n_rels_onemin_n_rels_twomax_n_rels_two

]project-open[ 2010, Data-Model / Frank Bergmann / 7

Exercises

Calculate the sum of all “percentage” assignments to all main projects in ]po[. Hint: The percentage is stored in table “im_biz_object_members”.

Calculate the sum of all financial items associated with a project, grouped by the type of financial item.

]project-open[ 2010, Data-Model / Frank Bergmann / 8

Frank Bergmannfrank.bergmann@project-open.com

www.project-open.com