]project-open[ Data-Model: Object-Relationships

  • 1,110 views
Uploaded on

This tutorial explains how to create generic relationships between OpenACS/]project-open[ objects. Sample relationships include the “is-member-of” relationship between users and business objects, but …

This tutorial explains how to create generic relationships between OpenACS/]project-open[ objects. Sample 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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,110
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
67
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Object-Relationships The ]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.
  • 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.
  • 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.
    Company Other Company User Project Other User is_customer (1:n rel) is_member is_member (project manager) is_member is_friend (Sample N:M Relationships between a user and several ]po[ objects)
  • 4. 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.
    rel_type object_id_two rel_id acs_rels object_id_one SELECT p.project_name, im_name_from_user_id(u.user_id) as user_name FROM acs_rels r, im_projects p, users u WHERE r.object_id_one = p.project_id and r.object_id_two = u.user_id user_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_id im_projects project_name . . . project_nr
  • 5. Relationship Types
    • Generic (“abstract”) relationship class
    rel_id im_biz_object_members object_role_id
    • Concrete group relationship
    • Concrete ]po[ membership
    percentage object_id object_type acs_objects rel_id acs_rels object_id_one object_id_two rel_type rel_id membership_rels member_state rel_id admin_rels rel_id composition_rels rel_id group_rels rel_type group_id rel_type acs_rel_type object_type_two role_one object_type_one role_two min_n_rels_one max_n_rels_one min_n_rels_two max_n_rels_two
  • 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 2 relationship 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_two role_one object_type_one role_two min_n_rels_one max_n_rels_one min_n_rels_two max_n_rels_two
  • 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.
  • 8. Frank Bergmann [email_address] www.project-open.com